Skunkware 98/Skunkware 98.iso/src/mail/sendmail.8.8.4.tar.gz/sendmail.8.8.4.tar/sendmail-8.8.4/contrib/converting.sun.configs

Text File | 1993-08-25 | 16KB | 447 lines

             Converting Standard Sun Config
              Files to Sendmail Version 8

                  Rick McCarty
             Texas Instruments Inc.
             Latest Update: 08/25/93 - RJMc

This document details the changes necessary to continue using your
current SunOS sendmail.cf with sendmail version 8.  In the longer term,
it is recommended that one move to using an m4 based configuration such
as those shipped with sendmail, but if you're like me and have made
enough modifications to your .cf file that you'd rather put that task
off until later, here's the sum total of my experience to get you to
version 8 with minimal pain.  I'll cover .cf as well as build issues.

Some background - as many are surely aware, Sun has some "special"
features in the sendmail they ship ($%x, %y LHS lookup, NIS alias DB
search, etc.).  (Some of those features can be had in alternative forms
in IDA sendmail, but v8 has picked up some IDA capabilities as well as
new ones, making it IMHO a most desirable version to go to.)  What I
will explain below includes v8 functional "equivalences" to these Sun
sendmail features.

So with that out of the way, let's begin.

First, some assumptions:

    1) I'm going to assume you've got sendmail version 8.6 or
       later in hand - if not, grab it from ftp.cs.berkeley.edu
       in the ucb/sendmail directory.  There are bugs in earlier
       versions which affect some of the needed functionality.

    2) Second, I'm going to detail this based upon the
       "sendmail.main.cf" configuration.  (BTW, if you attempt
       to move to using an m4 generated config in the future,
       MAIL_HUB is the feature which should provide similar
       functionality).

       In general, the changes will be similar for a subsidiary
       file, but since we (my TI group) funnel all non-local mail
       through our mailhost, we're not as interested in getting v8
       to run on such systems and I haven't tried it.

    3) You're using DNS and sendmail.mx.  If you're not, you ought
       to be, even if you're also running it along with NIS (which
       we do - except for gethostbyxxx() lookups, which I'll be
       talking about later).  I would imagine you could get things
       running OK without DNS support, but I haven't tried it myself.

    4) You're not mounting /var/spool/mail from other systems.
       I haven't found a v8 feature to guarantee this will work
       correctly.  Anyway, in the past, we've tried doing that
       here and found it to be a rather "ugly" feature, though
       Sun ostensibly supports it ("R" option).  Perhaps v8
       will one day have a similar feature, but for now, bottom
       line, I would recommend against it.

    5) You're not on Solaris or using NIS+.  I'm on 4.1.3.  I've
       looked at Solaris briefly and have noted that things are
       pretty much similar there except that they've moved some
       things into the /etc/mail directory.  I'd guess the
       executables aren't functionally all that different from
       what they had before - the configs are roughly the same.
       So I'd bet most of what I say in here will apply to
       Solaris.

OK, let's configure our sendmail.cf!  I'll just go from the top down...

              VARIOUS DECLARATIONS

1) For v8, you need to define your .cf as AT LEAST a version level 4
   configuration.  Add the following line:

    V4

   There are some issues regarding certain predefined macros - $w, $j, and
   $m.  With a V4 configuration:

    $w is defined to be the hostname, which will usually be fully
    qualified (i.e. "firefly.add.itg.ti.com").

    $j should have the same value as $w.

    $m will be predefined as the domain portion of $w
    (ex. "add.itg.ti.com").

   One note about this - if your configuration relies on the "w" macro to
   be the "simple" hostname (as mine does)...

   If the configuration version is 5 or larger:

    $w is supposed to be the "simple" name (ex. "firefly")

    $j should be the fully qualified name (i.e. "firefly.add.itg.ti.com")

    $m will be predefined as the domain portion of $j
    (ex. "add.itg.ti.com").

   I have not experimented with the various combinations, so I cannot
   guarantee you that the above definitions will always come out as
   expected.  Bottom line:  if your sendmail.cf depends on $w being the
   simple hostname, test it carefully or define the name explicitly,
   for example:

    Dwfirefly

2) To replace the Sun's "%y" feature, we must use a hostname mapping
   feature in v8.  If you want to do similar lookups with v8, you need
   to define the following map (we'll go over the rules that use this
   map later):

    Khostlookup host -f -m -a.

   This will define a "lookup only" map that is otherwise the same as
   sendmail version 8's built-in "host" map (see the "Sendmail
   Installation and Operation Guide" for details on this map.).

   An important note:  Whether or not these lookups will be done via
   NIS is a function of what gethostbyxxx() functions you link into
   your sendmail.  DO NOT redefine your host mapping to use NIS
   explicitly within sendmail - there can be unexpected behaviour if
   you do so (if you do any canonicalization in your .cf, you can get
   incorrect results, for one thing).

   For example, DO NOT TRY:

    Khost nis -f -a. hosts.byname

3) If you're doing reverse alias mapping as done in ruleset 22, instead of:

    DZmail.byaddr

   you'll need to declare the following:

    Kaliasrev nis -f -N mail.byaddr

4) If you are doing any other NIS map lookups, you'll need to define the
   map as done in the below example.  I have a "mailhosts" map, which I
   use to distinguish between local and non-local hosts.  Look at the
   sendmail doc for details on this stuff.

    Kmailhosts nis -f -m -a. mailhosts

5) You might wish to add the following line to support Errors-To: headers.
   I don't.

    Ol

6) Comment out/remove the following line:

    OR

   The R option means something different under v8 - check the documentation
   if you're interested in using it.

7) If you're running NIS and have a separate alias map, BELOW the
   following line where the alias file is declared:

    OA/etc/aliases

   ADD the following:

    OAnis:mail.aliases

   This will set things up so v8 will look at the local alias DB first,
   then the NIS map, just as Sun sendmail does.

8) Though you don't have to, I'd suggest changing:

    OT3d

   to use v8's warning feature, which allows a warning message to be
   sent if a message cannot be delivered within a specified period.
   I use:

    OT5d/4h

   which says - bounce after 5 days, warn after 4 hours.

9) I set the following option to be explicit about how I want DNS
    handled:

    OI +DNSRCH +DEFNAMES

10) The following line:

    T root daemon uucp

    may be deleted, though it will be ignored if you leave it around.

11) It would probably be good to change the version macro value (which
    shows up in "Received:" headers) so no one debugging mail problems
    gets the wrong idea about what config you're running under.  Look
    for something like:

    DVSMI-4.1

    Mine, for example is:

    DVADD-HUB-2.1

                RULESETS

1)  In ruleset 3, BELOW this rule:

    # basic textual canonicalization
    R$*<$+>$*        $2            basic RFC822 parsing


I add the following rule to remove a trailing dot in the domain spec so
it won't interfere with v8 mapping features, etc.  (Having a trailing dot is
not RFC-compliant anyway.):

    R$+.            $1

2) Because ruleset 5 is special in v8, I rename it to S95 and also change
   all RHS expressions containing ">5" to use ">95" instead.  In v8,
   5 is executed against addresses which resolve to the local mailer and
   are not an alias.  If you don't change S5 to something else, you might
   get a surprise!

3) If you're doing any lookups via the generalized NIS "$%x/$!x"
   mechanisms (such as with the mailhost map I referred to earlier) it's
   done differently under v8.  For example:

    DMmailhosts
    ...
    R$*<@$%M.uucp>$*    $#ether $@$2 $:$1<@$2>$3

   takes a different map definition and two rules under version 8:

    Kmailhosts nis -f -m -a. mailhosts
    ...
    R$*<@$+.uucp>$*        $: $1<@$(mailhosts $2 $).uucp>$3
    R$*<@$+..uucp>$*    $#ether $@$2 $:$1<@$2>$3

4) Sun has a special case of the "$%x" feature for host lookups - "%y" is
   automagically defined to do an NIS "hosts.byname" search with no other
   definition, as done in the below example:

    R$*<@$%y.LOCAL>$*    $#ether $@$2 $:$1<@$2>$3

   (Sun does this in more than one place.  But the above syntax is almost
    identical in each - mostly a case of changing names to protect the
    innocent.)

   In version 8, the predefined "host" map can be used to do essentially
   the same thing.  (However, whether or not it does an NIS lookup is
   a function of what gethostbyxxx() functions are linked in.)

   Recall the map definition I mentioned earlier in the DECLARATIONS
   section:

    Khostlookup host -f -m -a.

   Here's where we will use it.  It will take two rules:

    R$*<@$+.LOCAL>$*    $: $1<@$(hostlookup $2 $).LOCAL>$3
    R$*<@$+..LOCAL>$*    $#ether $@$2 $:$1<@$2>$3

   Note that this is almost verbatim the same change as was used in the
   previous "mailhosts" example.

5) Although Sun's default configs don't do this, because I mentioned
   canonicalization earlier, it deserves an example, as it's illustrative
   of the functional difference in the map definitions I discussed before.
   This stuff is also convered in the "Sendmail Installation and Operation
   Guide".

   Remember the built-in "host" map definition?  As you'll recall, unlike
   the "hostlookup" map we defined, "host" will actually CHANGE the
   hostname in addition to appending a dot.  "hostlookup" only appends a
   dot if the name is found and doesn't change it otherwise.  Anyway,
   here's the example:

    R$*<@$+>$*    $: $1<@$(host $2 $)>$3        canonicalize
    R$*<@$+.>$*    $1<@$2>$3            remove trailing dot

   Using the above, say you had input of:

    joe<@tilde>

    OR

    joe<@[128.247.160.56]>

    Assuming "tilde" or the IP address is found, it might be
        canonicalized as:

    joe<@tilde.csc.ti.com>

6) As another instance of the NIS lookup feature, with a slightly
   different twist, Sun implements reverse alias mapping in ruleset 22
   with the below:

    DZmail.byaddr
    ...
    R$-<@$->        $:$>3${Z$1@$2$}            invert aliases

   To use this feature under v8, change the above rule a (remember to
   define the alias map as I showed earlier):

    R$-<@$->        $:$>3$(aliasrev $1@$2 $)    invert aliases


               MAILER DEFINITIONS

1) Where "TCP" is defined in the "P=" and "A=" parameters of mailers, I
   changed it to "IPC".  Version 8 will accept "TCP", but "IPC" is
   preferred.

2) On all IPC mailers, I also defined "E=\r\n" and added an "L=1000" as
   in the below example:

    Mether,    P=[IPC], F=mDFMuCX, S=11, R=21, L=1000, E=\r\n, A=IPC $h

   The "E=\r\n" will save you headaches interoperating with such things as
   VMS TCP products.

   The "L=1000" is for RFC821 compatibility.  Not strictly necessary.

   I also removed the "s" (strip quotes) mailer flag Sun puts in for
   these mailers.  Stripping quotes violates protocols, which say
   clearly that you can't touch the local-part (left hand side of
   the @) until you are on the delivering host.

NOW.  If I haven't left anything out, you should be able to run through
your Sun sendmail.cf file and convert it to run under v8.

                  BUILD ISSUES

Some important notes on building v8 on SunOS:

Makefile

The default makefile in the version 8 source (src) directory assumes the
new Berkeley make.  Unless you want to go to the trouble of building it,
you can use your regular make, but you need to use a different makefile.
You can use "Makefile.dist" or "Makefile.SunOS" in the src directory.  I
made changes to get it to build so it is as compatible as possible with
the file/directory locations Sun uses.  Here are some relevant sections
out of my makefile:

    CC=gcc

    # use O=-O (usual) or O=-g (debugging)
    O=    -O

    # define the database mechanisms available for map & alias lookups:
    #    -DNDBM -- use new DBM
    #    -DNEWDB -- use new Berkeley DB
    #    -DNDBM -DNEWDB -DYPCOMPAT -- use both plus YP compatility
    #    -DNIS -- include client NIS support
    # The really old (V7) DBM library is no longer supported.
    # See READ_ME for a description of how these flags interact.
    #DBMDEF= -DNDBM -DNEWDB
    DBMDEF=    -DNDBM -DNIS

    # environment definitions (e.g., -D_AIX3)
    ENVDEF=

    # see also conf.h for additional compilation flags

    # library directories
    LIBDIRS=-L/usr/local/lib

    # libraries required on your system
    #LIBS=    -ldb -ldbm
    LIBS=    -ldbm -lresolv

    # location of sendmail binary (usually /usr/sbin or /usr/lib)
    BINDIR=    ${DESTDIR}/usr/lib

    # location of sendmail.st file (usually /var/log or /usr/lib)
    STDIR=    ${DESTDIR}/etc

    # location of sendmail.hf file (usually /usr/share/misc or /usr/lib)
    HFDIR=    ${DESTDIR}/usr/lib

For the resolver library, you can use the one shipped with Sun if you
want.  But I'd recommend using another version of the resolver library
(such as the one with Bind 4.8.3 or 4.9).  Sun's resolver stuff (at
least with 4.1.x) is quite old - I believe it is of 4.3.1 vintage.  (Do
you get the impression I don't TRUST what Sun ships with their systems?)

If you want NIS host lookup while maintaining DNS capability, you might
take a look at resolv+, which has NIS capable gethostbyxxx() functions
in it.  My recommendation, however, is to avoid doing NIS host lookups
in sendmail altogether, and to use a "pure" version of the resolver
library.

There are probably no situations (at least I think so) where it makes
any sense to link in Sun's NIS gethostbyxxx() functions from libc.
You could, I guess do it (I haven't tried it) and wind up with a
sendmail equivalent to the non-mx version Sun ships.  You'd need to
insure that NAMED_BIND is not defined in the build.  (If you do
this and have the "-b" DNS passthru option set in NIS, remember that
while you have some DNS functionality you'll not have any MX support.
(This, IMO, is what makes this a non-optimal choice.)

              INSTALLATION/TESTING ISSUES

The sendmail.hf file in the src directory should replace the one currently
in /usr/lib.  You also might choose to edit it a bit to "localize" what it
says.

The sendmail executable goes, of course, in /usr/lib in place of the current
one.  What I did was create a subdirectory in /usr/lib and put all of the
Sun sendmail stuff in there.  I named the v8 sendmail executable to be
sendmail.v8.mx and then symbolically linked it to sendmail.

One other thing.  If you use address test mode, keep in mind that
Version 8 is like IDA in that it does not automatically execute ruleset
3 first.  So say you're playing around with things testing addresses and
you're used to things like:

    0 [e-mail]

under v8 you need to say instead:

    3,0 [e-mail]

          INTEROPERABILITY ISSUES YOU MIGHT ENCOUNTER

Be aware that sendmail v8 issues a multi-line SMTP welcome (220)
response upon a client connection.  Most systems in your network should
handle it OK, but there are some that choke on it, because whoever wrote
the clients assumed only a single line.  THIS IS NOT SENDMAIL's FAULT.
A multi-line 220 response is perfectly valid.  A likely place you'll
encounter this problem is with non-Un*x SMTP clients.  If you do run
into it, you should report it to the vendor.

A final note about version 8 - if you follow the above configuration
scenario, you'll notice it doesn't like to get envelope sender
addresses it doesn't know how to get back to.  Sun sendmail would take
anything, even though it might not be able to bounce the message back
should something happen downstream.  So if another sendmail on a host
that's not locally known is trying to pump mail through your v8 host,
the ENVELOPE sender it gives had better be fully qualified.  This is
a GREAT thing, because it helps clear up problems we've had with not
being able to get things back to the sender, resulting in an
overburdened postmaster.

I hope this helps those running Sun sendmail feel more at ease with moving
on to v8.  It's really worth going to.